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REMARKS 

Claim 19 was rejected under 35 USC 1 12 because, according to the Examiner the 
limitation "the SR351 1 protocol" lacks sufficient antecedent basis. Applicants 
respectfully traverse. When there is only one thing in existence, such as "the World" or 
"the Intemet," one does not need to previously define "a world" or "an Internet" in order 
to establish a proper antecedent basis because there is no lack of clarity. The same 
principle applies to "the SR351 1 protocol" because there is only one such protocol. Note 
that claim 19 also specifies an "ITU-T protocol" because there may be more than one 
such protocol. 

Claims 1 and 16-21 were rejected under 35 USC 102 as being anticipated by 
Friedlander et al, US Patent 6,122,363. Applicants respectfully traverse. 

The Examiner asserts a correspondence between communication server 502 of the 
reference and the "database" of claim 1, and asserts a correspondence between 
transaction server 504 of the reference and the "intelligent peripheral" of claim 1 . The 
Examiner fiirther asserts that the transaction server receives the alert message of claim 1, 
stating 

e.g., protocol-specific service request message, See Claim 8, Claim 9 
and Claim 1 1 . 

Applicants respectfully disagree, and first note that claim 1 specifies that an alert 

message is sent firom the database to the intelligent peripheral which 

specifies a communications protocol for communication between said 
database unit and said intelligent peripheral. 

The claim does NOT state that the alert message comports, or is in accord, with some 

protocol. Rather, it states that the alert message specifies a protocol, and that specified 

protocol is for something other than the alert message; to wit; "for communication 

between said database unit and said intelligent peripheral" (emphasis supplied). 

Addressing the Examiner's reference to claims 8, 9 and 1 1, it is true that the term 

"protocol specific service request message" is found in claims 8, 9 and 11, but while it is 

clear that the message is a service request message - which suggests that it is not an alert 

message - , it is not at all clear fi-om the claim what the phrase "protocol-specific" means. 

Fortunately, claim terms must have support in the specification, and this term is indeed 
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mentioned in the specification, albeit only once. At col. 1 col. 1, lines 63-67 (within the 

"definitions" segment of the Background of the Invention section) the test states: 

Protocol Data Unit (PDU) - A message of a given protocol comprising 
payload and protocol-specific control information, typically contained 
in a message header. PDUs pass over the protocol interfaces that exist 
between the layers of protocols (per the OSI model). 

As best understood, this teaches that a PDU is a message that consists of a payload 

portion and a header portion, and that the header portion has control information that is 

protocol-specific. So, a PDU that operates in the context of protocol Z is a message that 

contains control information in its header that is recognized by a recipient of this message 

when that recipient operates according to protocol Z. (Note that the X.25 protocol is 

mentioned, and that the SS7 protocol is mentioned, in addition to the different protocol 

layers of the OSI model. Also the INAP, INAP+ and ADF protocols are mentioned.) 

It is respectfully submitted, therefore, that the claims pointed to by the Examiner 
refer to service request messages of a given protocol, and those messages carry control 
information that is protocol-specific. Those messages specify a service request, and the 
request contains protocol-specific information, but they do NOT specify a protocol for 
(subsequent) communication. 

This difference makes claim 1 not anticipated by the '363 reference. 

Further, clause (b) of claim 1 specifies 

with reference to a database within said intelligent peripheral, 
establishing a connection between said database unit and said 
intelligent peripheral to operate in accord with a protocol pointed to by 
said protocol parameter. 

The Examiner repeats this clause and basically attaches to it the assertion that the '363 

reference teaches this step. No support for the assertion is provided. 

Respectfully, the assertion is not supported by any teaching of the reference. 

Although the service application (520) of the reference is coupled to a database 
(col. 12, line 16), that database is used by the service application to extract therefrom 
information for a "dialing plan information field" and NOT for "establishing a connection 
between said database unit and said intelligent peripheral to operate in accord with a 
protocol pointed to by said protocol parameter." It is noted that there seems to be 
actually no teaching relative to the establishment of a connection between the 
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transactions serve and the communications server though, of course, connections exist 
(521, and 529). 

This difference makes claim 1 also not anticipated by the '363 reference. 

Further still, clause (d) of claim 1 (amended to correct an ambiguity) specifies 

communicating information between said switch and said intelligent 
peripheral over a bearer connection between them that is established for 
effecting said service, and associated with said call. 

The Examiner asserts that this step is taught in col. 8, lines 1-6. Applicants respectfully 

disagree. The sited passage (starting with the second word, which is the beginning of a 

sentence) states: 

Accordingly, the Communication Server distributes the service request 
only to an available Transaction Server that supports the service 
indicated by the Service Key. Transaction Server A returns service 
response 1 (e.g., "MONITOR") and call context to Communications 
Server A. Service response 1 is then communicated to the switch" 

This suggests that a communication Server can connect to a number of Transaction 

Servers, that a particular service request is sent to a particular one of the Transaction 

Servers (one that supports the service indicated by the Service Key), and that the 

Transaction server "returns," i.e., to the Communication Server, a "service response 1." 

There is no mention in this passage of any communicating of information between any 

switch (such as switch 506 in FIG. 5A or switch 560 in FIG. 5B and the transaction 

server. It is noted that FIGS. 5 A and 5B also do not show any connection between the 

Transaction server and any switch. Whatever communication the Transaction Server is 

involved with, it is solely with the Communications Server. 

This difference also makes claim 1 unanticipated by the '363 reference. 

To summarize, claim 1 differs from the '363 reference in at least three aspects, 
and each one of them makes claim 1 not anticipated by the '363 reference. 

Regarding claim 16, it is first noted that the Examiner has made no explicit 
assertions in support of the rejection. 

Like claim 1 it contains a step of a control element sending an alert message that 
specifies "a protocol to be used in interactions between the intelligent peripheral and the 
database." For the reasons expressed in connection with claim 1, this step makes claim 
16 not anticipated by the '363 reference. 
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Further, claim 16 specifies a step where the intelligent peripheral, in response to 

the alert message, selects 

from among a stored plurality of software modules, a software module 
for employing in implementing said interactions between the intelligent 
peripheral and the database according to the protocol specified in said 
alert message. 

Nothing like that is taught in the reference, and this fact constitutes another reason to hold 
claim 16 not anticipated by the '363 reference. 

Further still, claim 16 specifies a step where the control element (most closely 
corresponding to the Communication Server of the reference) sends a message to the 
switch that is triggered the following sequence of steps: the switch receives a call, sends 
information to the control element, the control element identifies a service, and sends the 
aforementioned alert message, "informing said switch of a bearer connection set up 
between said switch and said intelligent peripheral." No such message is taught in the 
reference, and no such bearer connection is taught by the reference (as demonstrated in 
connection with claim 1). This constitutes yet another reason to hold claim 16 not 
anticipated by the reference. 

A number of additional differences arc found in subsequent steps of claim 16. 
For one, the step of setting up the bearer connection is not found in the reference (which 
is not surprising since such a bearer connection is not employed in the reference). 
Additionally, the step of the intelligent peripheral performing a task requested by the 
control element "employing said bearer connection as necessary" is not found in the 
reference which, again, is not surprising since such a bearer connection is not employed 
in the reference. Additionally still, the step of the intelligent peripheral informing the 
control element that the task is completed is not found in the reference and that, too, is 
not surprising, for such a step is necessary only because the task may be completed 
without involvement by the control element, so the control element needs to be informed 
separately. Lastly, the step of dismantling the bearer connection is not found in the 
reference because, once again, there is no bearer connection to begin with. 

To summarize, there are many aspects of claim 16 - addressed above - which 
differ from the teachings of the '363 reference, and each one of them makes claim 16 not 
anticipated by the reference. 
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Claims 17-21 depend on claim 16 and they are, therefore, also not anticipated by 
the '363 reference. Moreover the dependent claims contain limitations that are not taught 
in the reference. 

The Examiner asserts that claim 17 is taught by the text at col. 8, lines 56-67. 

Applicants respectfully disagree. The text pointed to by the Examiner states, in part: 

An operation represents an INAP message type (e.g., PROVIDE 
INSTRUCTIONS, EVENT, etc.) in which the receiving process 
performs a specific operation in a stage of the call dialog, in accordance 
with the message type. 

This clearly indicates that the message causes the performance of a "specific operation in 

a stage of the call dialog," which is diametrically opposite of claim 17, which specifies 

that the alert message is "devoid of any request to perform any task pertaining to said 

call." Moreover, the message pointed to by the Examiner is NOT a message of the type 

that claim 17 specifies; to wit, an alert message "specifying a protocol to be used in 

subsequent interactions between the intelligent peripheral and the database." For each of 

these two reasons, claim 17 is not anticipated by the '363 reference, independently of the 

other limitations found in base claim 16. 

Regarding claim 18, which further limits the alert message, the Examiner points 
to col. 7, lines 16-27, but the pointcd-to passage docs not discuss any messages, and 
certainly not any message that contains the limitations of claim 18. As for claims 8, 9 
and 1 1 , these claims refer to "protocol-specific service request" messages. There is no 
teaching that such messages have the fimction to "solely to establish a protocol between 
said intelligent peripheral and said control element." In fact, if anything, the 
characterization of these messages (as "service request" messages) strongly suggest that 
their function is to request service. Again, this is diametrically opposite of what claim 18 
specifies. Therefore, it is respectfully submitted that claim 18 is not anticipated by the 
'363 reference, independently of the other limitations found in base claim 16. 

Regarding claim 20, the Examiner points to col. 8, lines 1-6 and to col. 8, lines 
30-67. As for the lines 1-6 passage, the arguments above demonstrated that this passage 
does not teach or suggest a bearer connection from the intelligent peripheral to any 
switch, and it follows, therefore, that it does not teach a connection as specified in claim 
20. The lines 30-67 passage also does not specify any bearer connection from the 
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intelligent peripheral to any switch. Therefore, it is respectfully submitted that claim 20 
is not anticipated by the '363 reference, independently of the other limitations found in 
base claim 16. 

Regarding claim 21, the Examiner asserts that the subject matter defined in claim 
21 is taught in cols, 7-8, lines 52-17. Applicants respectfully disagree. The passage 
pointed to by the Examiner pertains to FIG. 4. It is clear that FIG. 4 depicts service 
requests from Communication Server A to Transaction Server A, and corresponding 
service responses. There are NO messages that inform that a task was completed, 
preceded by (and hence separate from) from a step of "said intelligent peripheral sending 
results of said one or more tasks to said control element." Therefore, it is respectfully 
submitted that claim 21 is not anticipated by the '363 reference, independently of the 
other limitations found in base claim 16. 

In light of the above amendments and remarks, it is respectfully submitted that all 
of the Examiner's objections and rejections have been overcome. Reconsideration and 
allowance of claim 1, 16-21 are respectfully solicited. 

Respectfully, 
Wesley A. Brush 
James M. Camazza 
Romel Khan 

Dated: 10/3/2009 By /Henry Brendzel/ 

Henry T. Brendzel 

Reg. No. 26,844 

Phone (973)467-2025 

Fax (973)467-6589 

email brendzel@comcast.net 
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